home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19970626-19970929 / 000265_news@newsmaster….columbia.edu _Sat Aug 30 05:51:22 1997.msg < prev    next >
Internet Message Format  |  2020-01-01  |  4KB
  1. Return-Path: <news@newsmaster.cc.columbia.edu>
  2. Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30])
  3.     by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id FAA10468
  4.     for <kermit.misc@watsun.cc.columbia.edu>; Sat, 30 Aug 1997 05:51:18 -0400 (EDT)
  5. Received: (from news@localhost)
  6.     by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id FAA00750
  7.     for kermit.misc@watsun; Sat, 30 Aug 1997 05:51:17 -0400 (EDT)
  8. Path: news.columbia.edu!panix!howland.erols.net!cpk-news-hub1.bbnplanet.com!su-news-hub1.bbnplanet.com!news.bbnplanet.com!news.Stanford.EDU!nntp.Stanford.EDU!Cup.DSG.Stanford.EDU!jonathan
  9. From: jonathan@DSG.Stanford.EDU (Jonathan Stone)
  10. Newsgroups: comp.protocols.kermit.misc,comp.unix.questions,comp.unix.admin,comp.unix.misc,comp.unix.ultrix,comp.unix.shell
  11. Subject: Re: Do not get connected at 33.6K
  12. Date: 30 Aug 1997 09:48:32 GMT
  13. Organization: Stanford Distributed Systems Group
  14. Lines: 52
  15. Sender: jonathan@Cup.DSG.Stanford.EDU (Jonathan Stone)
  16. Message-ID: <5u8q9g$1ff$2@nntp.Stanford.EDU>
  17. References: <5tsn5b$o9q@newslink.runet.edu> <5u1fh6$n39$1@apakabar.cc.columbia.edu> <5u1mrf$il7@usenet.srv.cis.pitt.edu> <5u289d$3qi$1@nntp.Stanford.EDU> <5u41kn$5sb$1@apakabar.cc.columbia.edu>
  18. Reply-To: jonathan@DSG.Stanford.EDU
  19. NNTP-Posting-Host: cup.dsg.stanford.edu
  20. Xref: news.columbia.edu comp.protocols.kermit.misc:7582 comp.unix.questions:116191 comp.unix.admin:70343 comp.unix.misc:35316 comp.unix.ultrix:31811 comp.unix.shell:54387
  21.  
  22. In article <5u41kn$5sb$1@apakabar.cc.columbia.edu>, fdc@watsun.cc.columbia.edu (Frank da Cruz) writes:
  23. > In article <5u289d$3qi$1@nntp.Stanford.EDU>,
  24. > Jonathan Stone <jonathan@DSG.Stanford.EDU> wrote:
  25. > : The preferred Ultrix software interface for ttys is POSIX-compatible
  26. > : termios.  I have no idea what C-Kermit uses.
  27. > : 
  28. > Not to prolong this unnecessarily, but C-Kermit supports all versions of
  29. > Ultrix back to 1.0, which probably predates POSIX.1.
  30.  
  31. Do you mean version 1 of Ultrix-11 or of ultrix32/ultrix-32m?  All
  32. predate 1988, and therefore POSIX.1.  I'd be pleasantly suprised if
  33. C-Kermit links successfully on Ultrix-11 systems with split I/D, and
  34. hugely suprised if it links on Ultrix-11 systems without split I/D.
  35. (ISTR early Ultrix relases ran on 11/34s.)
  36.  
  37. Still, I assume you know this best...
  38.  
  39.  
  40. >  I'm perfectly willing
  41. > to add any code necessary to support higher serial speeds and hardware flow
  42. > control, but I have yet to see any evidence that these are supported by any
  43. > version of Ultrix.
  44.  
  45. Ummm, have you tried ioctl(fd, TIOCMSET, ....)?
  46.  
  47. AFAIK this ioctl is present in Ultrix 4.0 and was used by SLIP and
  48. PPP, though it may not be documented anywhere, and may not have been
  49. in earlier versions.  Ask someone with access to Ultrix source code
  50. for the mode bits to enable RTS and CTS; I beleive they're
  51. device-independent, at least for DECstations.
  52.  
  53.  
  54. > Finally, regarding all the jumpers, external clocks, etc, obviously those
  55. > are not Kermit issues, but I trust that if some Ultrix version supports
  56. > some baud rate, say B57600, and the software tries to set it on a physical
  57. > device that does not support it, that the driver will return the appropriate
  58. > error status code.
  59.  
  60. Obviously jumpers and external clocks are not Kermit issues.
  61. My apologies. 
  62.  
  63. But this thread *is* quite widely cross-posted, including comp.unix.ultrix.
  64. The things I referred to earlier were hardware issues. I was
  65. specifically correcting some not-quite-correct posts about what
  66. DECstation _hardware_ is capable, which I read on
  67. comp.unix.ultrix. (NetBSD is on-topic there, and NetBSD supports
  68. hardware features that Ultrix doesn't.)
  69.  
  70. As best I know, Ultrix itself does not support speeds above 38400.
  71. Supporting NetBSD-specific DECstation features (like speeds above
  72. 38400 or modem control) is something we should probably discuss via
  73. e-mail, if it needs any explicit support at all.